


Institutional Archive of the Naval Postgraduate School 





Calhoun: The NPS Institutional Archive 
DSpace Repository 


Theses and Dissertations 1. Thesis and Dissertation Collection, all items 


1997-03 


Development of an on-line failure mode 
detection and resolution algorithm for the 
Phoenix AUV 


Hurnt, Michael A. 


Monterey, California. Naval Postgraduate School 


http://ndl.handle.net/10945/8263 


Downloaded from NPS Archive: Calhoun 


Calhoun is the Naval Postgraduate School's public access digital repository for 


' (8 D U DLEY research materials and institutional publications created by the NPS community. 
: Calhoun is named for Professor of Mathematics Guy K. Calhoun, NPS'‘s first 
ath 
KNOX appointed — and published — scholarly author. 


i LIBRARY Dudley Knox Library / Naval Postgraduate School 


411 Dyer Road / 1 University Circle 
Monterey, California USA 93943 








http://www.nps.edu/library 


NPS ARCHIVE 
1997.03 
HURNI, M. 


NPS-ME-97-001 
NAVAL POSTGRADUATE SCHOOL 
MONTEREY, CALIFORNIA 





THESIS 


DEVELOPMENT OF AN ON-LINE FAILURE 
- MODE DETECTION AND RESOLUTION 
ALGORITHM FOR THE PHOENIX AUV 
by 


Michael A. Hurni 


March, 1997 
Thesis Advisor: Anthony J. Healey 


Thesis 


moo 7 15 





Approved for public release; distribution is unlimited. 
Prepared for: 
Office of Naval Research, 
800 North Quincy St., Arlington, Virginia 22217-5660 





JUDLEY KNOX LIBRARY 
NAVAL POSTGRAD: «a TE SCHOO! 
MONTEREY Ca 93943-5104 





REPORT DOCUMENTATION PAGE | temsrmonsonare ia | 


Public reporting burden for this collection of information 1s estimated to average | hour per response, including the time for reviewing instruction, searching existing data 

| sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any 

| other aspect of this collection of information, invading sugetstivts for reducing this burden, to Waslinigton Headquarters Services, Directorate for Information . 
Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction 
Project (0704-0188) Washington DC 20503. 


1. AGENCY USE ONLY (Leave blank) Zz REPORT DATE 3. REPORT TYPE AND DATES COVERED 
March 1997 Master’s Thesis 


4. TITLE AND SUBTITLE: DEVELOPMENT OF AN ON-LINE FAJLURE |5. FUNDING NUMBERS 
MODE DETECTION AND RESOLUTION ALGORITHM FOR THE _ | N0901497AF00002 


PHOENIX AUV 


6. AUTHOR(S) MICHAEL A. HURNI 
(ke 


PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) . PERFORMING 
Naval Postgraduate School ORGANIZATION 


Monterey CA 93943-5000 REPORT NUMBER 
NPS-ME-97-001 


9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) Office of | 10. SPONSORING/MONITORING 
Naval Research, 800 N. Quincy St., Arlington, VA 22217-5660 AGENCY REPORT NUMBER 

11. SUPPLEMENTARY NOTES The views expressed in this thesis are those of the author and do not reflect the 
official policy or position of the Department of Defense or the U.S. Government. 


12a. DISTRIBUTION/AVAILABILITY STATEMENT 12b. DISTRIBUTION CODE 
Approved for public release; distribution is unlimited. 


13. ABSTRACT (maximum 200 words) 





It has become apparent that in order for an AUV to be a more reliable self-sufficient system, it must have 
on-line failure detection and resolution capability. In support of this the AUV must have reconfigurable 
systems so as to be able to take corrective action against resolvable failures. A simulator has been designed 

| using SIMULINK in order to analyze failure modes associated with the NPS Phoenix AUV steering system. 
The analyses of these failure modes have been used to identify possible signals for steering system fault 
detection. Finally, a rule based algorithm was developed which can be converted into a format that ultimately 
could be implemented in a fuzzy logte set, for later insertion intu the Phoenix tactical level software. This 
methodology will be applied to the Navy's UUV. 


15. NUMBER OF 


SUBJECT TERMS: AUTONOMOUS SYSTEMS, ROBOTICS, FAULT 


DETECTION PAGES 106 





16. PRICE CODE 


ye oeCURITY ClASSIFI- 18. SECURITY CLASSIFI- : 19. SECURITY CLASSIFICA- | 20. LIMITATION OF 
CATION OF REPORT CATION OF THIS PAGE TION OF ABSTRACT ABSTRACT 








Unclassified Unclassified Unclassified DE 


NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89) 
Prescribed by ANSI Std. 239-18 298-102 


il 





Approved for public release; distribution is unlimited. 


DEVELOPMENT OF AN ON-LINE FAILURE MODE DETECTION AND 
RESOLUTION ALGORITHM FOR THE PHOENIX AUV 


Michael A. Hurni 
Lieutenant, United States Navy 
B.S., University of New Hampshire, 1989 


Submitted in partial fulfillment 
of the requirements for the degree of 


MASTER OF SCIENCE IN MECHANICAL ENGINEERING 
from the 


NAVAL POSTGRADUATE SCHOOL 
March 1997 





ae 





QUDLEY KNOA crore ; 
AVAL POSTGRADUATE SCHOO: 


MONTEREY CA 93943-5101 


ABSTRACT 


It has become apparent that in order for an AUV to be a more reliable self- 
sufficient system, it must have on-line failure detection and resolution capability. In 
support of this the AUV must have reconfigurable systems so as to be able to take 
corrective action against resolvable failures. A simulator has been designed using 
SIMULINK in order to analyze failure modes associated with the NPS Phoenix AUV 
steering system. The analyses of these failure modes have been used to identify possible 
signals for steering system fault detection. Finally, a rule based algorithm was developed 
which can be converted into a format that ultimately could be implemented in a fuzzy 
logic set, for later insertion into the Phoenix tactical level software. This methodology 
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I. INTRODUCTION 


A. GENERAL BACKGROUND AND LITERATURE 


Over the past decade more and more research has been devoted to the 
development of Autonomous Underwater Vehicles (AUV's). The potential for AUV's 
is large and eventually, even Remotely Operated Vehicles (ROV's) will incorporate 
some of the new AUV technology. The potential commercial and military uses for 
AUV's far out number those of ROV's, not to mention the benefits it can provide to 
ocean science research. Simply put, AUV's are our future. 

Technology of AUV's has come a long way over the last decade. However, 
much research must still be conducted in all areas of AUV technology. Some of the 
more recent works are cited here to show the broad spectrum of study that is still 
ongoing. Healey and Lienard (1993) have shown that a multivariable sliding mode 
autopilot based on state feedback, designed assuming decoupled modeling, is quite 
satisfactory for the combined speed, steering, and diving response of a slow speed 
AUV. Marco and Healey (1996) have demonstrated a method to navigate an 
autonomous underwater vehicle in a local area using an acoustic sensor for position 
information derived from feature detection. Further developments have been achieved 
by Healey, et al. (1994) in hover control behavior using the ST1000 and ST725 high 
frequency sonars to provide data about the environment. Byrnes, et al. (1996) has 
proposed a tri-level control system architecture called the Rational Behavior Model 


(RBM) as an approach to autonomous and automatic control of systems. A work 


which describes the advantages of AUV's over ROV's or manned submarines was 
written by Marco (1996), in which he designed and verified a working hybrid control 
system combining mission management with robust motion controllers. 

An area which is now receiving more focused attention is Failure Modes and 
Effects Analysis (FMEA). This 1s because it is becoming more readily apparent that 
in order for an AUV to be a totally self-sufficient system, it must have an on-line 
failure detection and resolution algorithm. This algorithm must work in tandem with 
an AUV whose systems are reconfigurable. The scope of this work takes a very small 
step towards this goal. Its purpose is to design an effective failure detection and 
resolution algorithm for one subsystem (steering) of the NPS Phoenix. The Phoenix 1s 
an underwater vehicle used by the Naval Postgraduate School to conduct AUV 
research. 

Previous literature pertinent to this particular area of research is very abundant. 
A brief summary of some basic fault detection methods along with some examples can 
be found in Isermann (1984). The examples provided were detecting faults in an 
electrically driven centrifugal pump and leak detection for pipelines. Healey (1993) 
discusses the use of both batch least squares and Kalman Filters for system parameter 
identification as a means to detect a change in performance. Bell, et al. (1992) has 
developed a tool that automates the reasoning portion of an FMEA. The prototype has 
been created and successfully passed a test and evaluation program. A program which 
automates the prediction of the effect of failure modes for electrical systems has been 


developed by Hunt, Price and Lee (1993). This program is called FLAME (Functional 


Level Analysis of failure Modes and Effects). Finally, Healey (1992) addresses the 
use of Kalman Filters and Artificial Neural Networks to provide the detection, and 
isolation of impending system failures. 

For some time the Navy has funded the development of software tools for 
performing automated on-line system fault detection. It has been agreed, however, that 
too much detail can lead to unwieldy systems. Also, for a useful automated diagnostic 
system to be able to improve the reliability of AUV's, only those problems that can be 
mitigated during a mission need to be identified. Therefore, this work concentrates on 
“subsystem level" fault detection rather than "component level" detection. The 
difference lies in the granularity established by the system models used as the 
detection basis. In principle, a diagnostic system is only able to detect faults at the 
level of its design model basic granularity. For instance, if a subsystem or component 
(G) 1s modeled by its input, output and disturbance signals (Figure 1.1), we can, under 
some conditions relating to the observability of the system model, infer the satisfactory 
operation of the subsystem (G) with regard to a desired behavior. If a model based 
filter 1s proposed for the control signal (e,) such that G, 1s a model for G, changes in 
G from any source are detectable through the input/output signals (u, Y) and in 


particular the servo error (€, = Yoom - y? and the observer error (e, = Y - y) The 


com 


input signal (u) is determined by the system controller (C). 


B. SCOPE OF THIS WORK 


The driving force of this thesis 1s threefold: 1) Earlier work by Bahrke (1992) 
broke down the Phoenix AUV into separate subsystems and generated equations that 
could be used to model these systems. The work in this thesis seeks to show that 
these equations can, with reasonable accuracy, model the AUV steering system using a 
CAD program such as SIMULINK in MATLAB. 2) The simulator designed in this 
work is used to conduct an intensive study of all the possible failure modes that could 
be related to the steering system. 3) Armed with the knowledge provided by all the 
simulations, an algorithm is developed whose purpose 1s to detect steering system 
failures and reconfigure the system (when necessary) to operate efficiently, or abort the 
mission. 

Chapter II focuses on the design of an effective, user friendly, FMEA simulator 
geared towards the NPS Phoenix AUV (Figure 1.2) steering system. It was very 
important in this chapter to ensure that the vehicle was accurately modeled. However, 
major emphasis was given toward user friendliness, because future work in this area 
will require the ability to operate and possibly change the simulator. 

Chapter IJJ categorizes the various failure modes that could occur, simulates 
them and places these results in tabular form to help determine their distinguishing 
features. Further study is done to show which failure modes can be ignored (small 
effect on system), which ones must be prevented at all costs (either devastating to the 


system or undetectable), which ones will require system reconfiguration to ensure 


continued effective operation and which ones will require a mission abort. How the 
steering system should be reconfigured for various failures is also addressed. The 
ultimate goal of developing a useful algorithm for failure detection and resolution was 


then realized. 


disturbance 
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Figure 1.1 Simple Example of Subsystem Modelling. 











From Marco (1996). 


Figure 1.2 Nava' Pcstgraduate School 'Phoenix' AU’. 





Il. DESIGN OF A STEERING SYSTEM FMEA ANALYSIS TOOL 


A. INTRODUCTION 


The purpose of this chapter 1s to show the steps taken in the design of a 
steering system failure modes and effects analysis (FMEA) tool. This FMEA tool is 
specifically designed to simulate (using MATLAB/SIMULINK) the response of the 
NPS Phoenix AUV to various failures that could occur in its steering system. 
Naturally, the design had to be carried out in steps. The dynamics of the vehicle in 
response to steering system commands had to be simulated first. Once that was 
achieved, a PD controller was designed, and then a state estimator. Finally, a method 
of artificially inserting failures into the system was added to the simulation. The 
overall block diagram is shown in Figure 2.1. Figure 2.2 may be useful in 


understanding the geometry and axes definitions of the AUV. 


B. VEHICLE DYNAMICS RESPONSE TO SPEED AND RUDDER INPUTS 


It was shown by Fossen (1994) that the response of the vehicle to speed and 
rudder inputs can be reduced to a force equation, a moment equation and the three 


Euler equations relating XY Y and ,,. It was assumed that the vehicle operates in 


¥ 


level flight without roll, and that body drag forces are negligible. The resulting 


equations are: 


my +mx,f - YF - Y,v = -mur + Yur +Yuv+u7(Y, 3,5 +%5 5,5) 
Li +mx,) -NF-N,p = -mx our +Nur+Nyuv+u7(N, 3,,+N, 5,,) 
X =ucos¥ -vsin¥ 
Y =usin¥ +vcos¥ 
Y =r 


The following additional assumptions were made by Bahrke (1992): 


1. The bow and stern rudders operate with equal magnitudes of deflection but 
opposite direction (6,, = -6,,). 


2. The size and shape of the bow and stern rudders 1s identical (Y; = Ys, = 
N55): 


3. From vehicle geometry N;, = 0.283LY, and Ng, = -0.37/LYs. 


Along with these assumptions the two rudder inputs (6,,, 6,,) were divided up into four 


Ts? 


inputs (5,,., 5,., 5,,,, 5,,) for simulation purposes. This allows any one rudder input 
to be altered for the purpose of rudder failure insertion and, ultimately, the analysis of 
the effects of that failure on the vehicle. Using the above relations and rearranging, 
the force and moment equations can be written as follows: 
(m-Y.)v+ (mx, - Y)r=Y uv +(¥_-m)ur +0.5u7Y,(8_, + 8, + 8, + 51.) 
(mx, -N,)v +, - Nr = 
N uv +(N_-mx,)ur + 0.5Lu7Y 30.283(5, + 5,,,) -9.377(5,,. + 5,.)] 


In order to model the force and moment equations above, it 1s necessary to 


determine the values of the constants and coefficients that appear in the equations. 


10 


Appendix A contains the values of these constants and coefficients (Bahrke, 1992). 
However, the coefficients are in their dimensionless form. Thus it is necessary to 
dimensionalize the coefficients such that each term in the force equation has units of Ibs. 
and each term in the moment equation has units of Ibs.-ft. The coefficients of the 


Phoenix AUV were dimensionalized by multiplying each one with the appropriate form 


of 0.5pu "L” (Healey, 1996). The resulting equations were rearranged such that the 


force equation was solved for v and the moment equation was solved for 7. They are 


shown here in their final form for simulation: 


¥ = -0.190597r - 0.2090 luv ~0.51091ur +0.011525u7(5,, +6,, +5, +6, ) 
F = -0.09263¥ -0.19988ur +0.0408872u 7[0.283(6, , +5, ,) -0.377(6,,. +5, J] 


al 
urb 


The above two equations along with the equation for Y were used to form the Steering 


block of Figure 2.1. 

The steering system model is shown in Figure 2.3. The inputs to the model are 
the forward speed of the vehicle (u) and the four rudder deflections (6,)). Speed is varied 
by changing the output value of the Speed block of Figure 2.1. The rudders get their 
commands from the output of the PD controller block. The outputs of the model are 
sway velocity (v), yaw rate (r) and heading angle (Y’). The last things added to the model 
were two files containing random, low frequency, system noise (noisel.mat and 


noise2.mat). These system noise files were added to the right sides of the v and 


1] 


; equations. They simulate the added forces and moments that occur naturally due, 


mainly, to wave action in the water. Appendix B contains the MATLAB program 
(obtained from professor Healey) used to generate these system noise files. 

The XY output block of Figure 2.1 was created so that a graph of the vehicle's 
XY position could be plotted. This graph further aids in understanding the vehicle's 
response to various failure modes. The internals of this block are shown in Figure 2.4. 


The XY output is plotted as a function of the inputs u, v and V. 


C. PD CONTROLLER DESIGN 


In order to design a PD controller the equations for ,4, » and ,s, had to be 


v’>r Wp 
linearized about a single velocity and then placed in their state space form: 


JESU Seay ahs) 


The form that 1s shown above requires that the four rudder inputs be combined into 


one commanded rudder input (6,,,,). The controller design involves pole placement to 


find a 1x3 matrix (k) such that the control law is 6,.,, = -kx. Linearization was done 
about u = 1 ft/s and the 3x3 A matnx had one eigenvalue at zero and the other two 
were complex with real parts at -0.1840. Given these particular eigenvalues the three 
poles were placed at about -0.2 to approximately match the open loop poles at - 


0.1840. The resulting gain matrix was k = [0.3587 4.29 0.6949], which produced the 


following control law: 
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8», = -0.3587v - 4.297 - 0.69498 


There are two problems with the above control law. The first problem is that it 
is based on a model that was linearized about u = 1 ft/s. If the vehicle is travelling at 
u = 3 ft/s the control law is too fast and the vehicle makes a tighter turn than it 
should. We want a controller that will allow the vehicle to follow the exact same path 
regardless of its speed. The solution to this problem is to perform the above controller 
design procedure for various values of u in the hopes of determining a relationship 
between the controller gains and u. If this relationship can be found then a nonlinear 
controller design can be obtained with controller gains properly varying as a function 
of u. The second problem is that v, r and Y¥ go to zero in steady state (6,,,, = 0). It's 
desirable to have v and r go to zero, but ‘Y should reach some commanded heading 
eieen 

The solution to the first problem is as follows. It was determined that k, and 
k, vary inversely proportional to u, however, changing u had absolutely no effect on 
k,;. The second problem was solved simply by subtracting YY... from ‘¥. The block 


diagram of the PD controller is shown in Figure 2.5. Here is the final control law: 


8 = +(-0.35879 - 4.298) - 0.6949(8 - ¥ 
u 


com) 


The inputs to the controller are u, yw, 4, ., and Y,,,,. The State Estimator block of 


y’ 2 Wy 


| 


Figure 2.1 provides ~ P and oe The commanded heading block of Figure 2.1 


provides ‘V..... The controller has two outputs; one for the bow rudders (6,,,,) and one 
for the stern rudders (-6,,,,). 

Commanded heading is determined by a switching network (Figure 2.6). It has 
a Clock input which controls the switches to allow the output (‘Y..,,) to change at the 
desired time during the simulation. This allows the steering system to receive 


different heading commands during the simulation. 


D. STATE ESTIMATOR DESIGN 


The design of the state estimator followed closely the design of the PD 


controller. The equations for ,,, » and ,*, were linearized about a single velocity 


wer yp 


and then placed in 


the following state space estimator form: 


Xx =AX + BS... + Lex) 


It is assumed there are only sensors for r and ‘Y, and that v has only an estimated 


value (5). Therefore, there are only two observer errors (e,, and e,y). Since e,) 1S a 


2x] matrix the observer gain matrix (L) must be 3x2. Linearization was done about u 
= ] ft/s and pole placement was performed to obtain L. Following normal convention 


the observer poles were placed at -0.4, which is twice the distance from the origin as 
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the controller poles. The following observer gain matrix was realized: 


[L,, Ly; Ly Ly Ly Lg = [1.2025, 0.0; 0.4219, 0.0; 1.0, 0.41] 


Again there 1s the problem that the state estimator is based on a linear model. 

If the vehicle is travelling at u = 3 ft/s, the estimator will be too slow. There must be 
a relationship between u and L. The state estimator design was performed using 

various values of u, and it was determined that L,, L, and L, do not change at all as u 
is changed. However, it was discovered that L,, L; and L, are directly proportional to 
u. The State Estimator block is shown in Figure 2.7. This block has the same inputs 
as the steering block but also has the sensor inputs r and ‘V. It is essentially the same 
block as the steering model with an added term (Le,)). The outputs are the estimated 
values of v, r and ‘V (y, p an 


d wp): 


E. FAILURE MODE INSERTION 


In order to study the effects of various failure modes, a method must be 
installed to allow failures to be easily inserted into the simulation. Steering system 
failures can be cataloged into two basic groups: Rudder failures and sensor failures. 


Rudder and sensor blocks were added to achieve this goal. 


1. Rudder Blocks 
Four rudder blocks were installed (one for each rudder to match the Phoenix 


configuration), as can be seen in Figure 2.1. It is relatively easy to modify the 
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simulation to match other AUV configurations such as that proposed for the Navy's 
UUV. The diagram of a rudder block is shown in Figure 2.8, and it can be seen that 
it is a Switching network much like the commanded heading block. It has two inputs, 


6 


and Clock. The clock input is used to control the switches to insert a failure in 


com 


6 


com at any time during the simulation. It is capable of simulating many failures such 


as stuck rudder, hard rudder, loose rudder or limited rudder. The output of a rudder 


block is either the ordered rudder position or the failed rudder position. 


Zz Yaw Rate Sensor Blocks 

Building a block that can accurately simulate the output of a sensor and the 
output of a failed sensor is again done with the use of switches. The clean output 
signal is picked off of the Steering block and then corrupted with noise. The noise is 
added to make the simulation more realistic since no sensor can provide a totally 
noise-free output. The clean signal and the noise each have their own sensor block to 
allow one of them to be modified during the simulation without affecting the other. 
For example, a signal with an unusually high noise level could be simulated, or the 
noise level may be normal but the signal itself is incorrect. Problems that could occur 
with a sensor besides increased noise are: saturation, loss of input, loss of output and 
constant bias. 

A typical sensor noise block is shown in Figure 2.9. The Clock input controls 
the time at which the problem of high sensor noise would occur (if so desired in the 


simulation). Basically, the block takes the noise input and adjusts its level for output 
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to be added to the clean sensor signal. Figure 2.10 shows a sensor signal block. It 


takes the clean signal, corrupts it and sends the output to be added to the noise signal. 


3. Heading Angle Sensor Blocks 

Obviously the primary sensor for the steering system is the heading sensor, and 
it will be proven later that any failure of this sensor is catastrophic. Armed with this 
knowledge the Psi sensors block was added to Figure 2.1. This block assumes that 
since the heading sensor is so important the vehicle will be equipped with three of 
them. It is shown in Figure 2.11. It has three sensor and three noise blocks so as to 
simulate a problem with one or more of the three sensors at a specified time using the 
Clock input. The other two inputs are the clean signal (‘¥) and the estimated signal 


~ ). Three values of observer error (e€,.), one for each sensor, are calculated. These 
y of 


observer errors are fed into a function (see Appendix C), similar to a median filter, 
which extracts any suspect errors and averages the rest. A suspect observer error 1s 
one which exceeds a certain small threshold. The threshold is simply chosen to be 
slightly greater than acceptable noise amplitudes. This is because during normal 
steering system operation e,y should only contain zero mean noise. In the case of all 
three errors being suspect (such as when a steering system failure occurs) the function 
simply averages them all. The output of this block is the average e,y which is sent to 


the State Estimator block of Figure 2.1. 


leg 


F. SUMMARY 


This chapter has shown, step by step, how an FMEA tool was designed so as 
to study the NPS Phoenix AUV steering system. Much had to be known about the 
dynamics of the AUV in order to produce a working simulator. The use of switches 
in sink with a running Clock helped make the simulator more user friendly. The user 
simply has to change the settings of these switches to create the desired simulation. If 
input files had been used rather than switches, the user would have to edit the files 
every time the simulation was changed. It has been noted here that there are other 
ways to insert failures and rudder commands, but the method used in this work was 
deemed to be the easiest to understand and the most user friendly. The remainder of 
this work seeks to accomplish a thorough analysis of the Phoenix AUV steering 
system using the newly designed FMEA tool. The final task will be to establish an 
algorithm that can be incorporated in the Phoenix software for failure detection and 


resolution. 
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Figure 2.2. Gccrsetry and Axes Definitions (Positive Conventions Shown). 
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Il. PHOENIX AUV STEERING SYSTEM FAILURE MODES ANALYSIS 


A. INTRODUCTION 


The purpose of this chapter 1s to show the results of a comprehensive FMEA 
on the Phoenix AUV steering system. First it was determined what types of failures 
could occur involving the steering system. Each of these failures was then simulated 
using the FMEA tool already designed (Chapter II), and each one was compared to the 
normal (trouble free) response. The results of these simulations were put in tabular 
form from which they could be studied (for similarities and trends) and further 
categorized. These studies resulted in many important conclusions involving vehicle 
dynamics, failure detection and in some cases failure prevention. Further analysis 
helped formulate possible solutions to the failures. The end result is an algorithm 
which, when converted to the proper form, can be incorporated in the Phoenix 


software for failure detection and resolution. 


B. FAILURE CATEGORIZATION 


In analyzing the AUV steering system it was determined that any failure 
occurring on the vehicle, if it had any effect on the steering system, could be 


categorized as one of two types: 


1. Rudder Failures 


2. Sensor Failures 


A 


There are five possible rudder failures that can occur: 


(1) Loose Rudder:The rudder in question will not respond (stuck at zero). For 
the Phoenix (which has four rudders) the other rudders can still turn the 
vehicle, however its response to course changes will be slower. 


(2) Stroke Limited Rudder:The rudder in question does not have its full range 
of motion. As in the Joose rudder case, the vehicle will simply respond more 
slowly to course changes. 


(3) Stuck Rudder:A rudder is stuck in some position other than zero; the 
special case of a rudder stuck at zero is considered in this work as a Joose 
rudder. In this case the remaining rudders must turn to counteract the yaw rate 
caused by the stuck rudder. Once this has been done the vehicle will no longer 
be heading in the commanded direction, and vehicle response to further course 
changes will be slowed as in the /oose or stroke limited cases. 


(4) Hard Rudder:A rudder is stuck in the hard right or hard left position. This 
is simply a special case of stuck nidder. 


(5) No Rudder Response:All rudders are stuck at zero. In this case the vehicle 
steering system would not respond at all to commanded course changes. 


There are also five possible sensor failures. Since the steering system has two 
sensors of interest these failures would have to be applied to each sensor, resulting in 


ten sensor failure modes. The five possible yaw rate sensor failures are as follows: 


(1) Increased Noise Level:The more noise that a sensor reads the harder it 1s 
to determine the actual value of the parameter being measured. This 1s a very 
difficult failure to detect. The intent of modelling this failure is to show that 
the steering system can operate effectively with as high as a ten fold increase 
in noise level, thus eliminating the need for detecting it. 


(2) Loss of Input:In this case the state estimator will only receive noise from 
the yaw rate sensor. Since the steering system parameters are fully observable 
with the heading sensor alone, a loss of the yaw rate sensor should have only a 
small effect on the vehicle's steering system performance. Detecting this 
failure may not even be necessary. 
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(3) Loss of Output:Once the increased noise level scenario is proven to have little 
effect, the results of this failure should be the same as a Joss of input, since the 
state estimator is getting zero from the sensor rather than noise. 


(4) Sensor Saturation:The state estimator gets a large value of yaw rate. In order 

to reduce the controller signal to the rudders to zero (so the vehicle doesn't go in 

circles) the estimated value of heading will be incorrect. The result of this failure 

should be a large change in heading without the command to do so. 

(5) Sensor Bias:The bias in yaw rate will cause an incorrect estimate of heading 

as in the saturated sensor case. Again, the result should be an uncommanded 

heading change. The amount of heading change will depend on the size of the 

bias. 

It is assumed that since the heading sensor is the primary sensor for the steering 
system, failures of that sensor should be prevented. However, the following two failure 


modes were studied in order to show the severity of such failures and the need for 


prevention: 


(1) Stuck Heading Sensor: With a stuck heading sensor the vehicle would respond 
to course changes by going in circles because it would never reach its commanded 
heading. 

(2) Heading Sensor Bias: With a heading sensor bias the vehicle's course would 
always be off by the amount of the bias. This failure is impossible to detect. 

The actual failures studied in this work, along with a complete description of each 


failure's simulation scenario, are listed in Table 3.1. It should be noted that each 
simulation starts with the same initial heading and speed (Y = 0.0 rads, u = 3 ft/s). 


GC. PLACING SIMULATIONS IN TABULAR FORM 


Each scenario of Table 3.1 was performed twice; once without a failure and once 


with the failure inserted. The FMEA results are displayed in Table 3.2. The first column 


ae 


of Table 3.2 lists the failure modes. The next nine columns represent the signals that 
would be available to the AUV for analysis. The following entries appear in these 
columns: 

'NU ----- No difference between the normal and failed responses. 

SD wee A steady state difference exists between the normal and 
failed responses. 

'T!  ----- A transient difference exists between the normal and 
failed responses. This means the two responses coalesce 
in steady state, making detection more difficult. 

TT seeee The difference between the normal and failed responses 
increases without bound. 

Column 11 indicates the failure severity (FS). Entries include: 
Lo weno Low: failure's effect is small; no correction required. 
‘Mi ----- Medium: failure's effect is large enough to require 
correction such as sensor removal, gain changes and/or 
bias insertions. 

'H' ----- High: failure is not correctable or the AUV can not 
operate effectively. 

The last column in Table 3.2 indicates the difficulty of detection (DD). Possible entries 
are: 


'L' wee Low: can be detected in steady state using available signals. 


0 


'M' ~~ ----- Medium: Since the normal and failed responses are equal 
in steady state, a maneuvering transient is required for 
detection/verification of failure. 


'H' — ----- High: not detectable. 


D. DISCUSSION OF RESULTS 


In order for the AUV to be able to detect failures and respond accordingly, the 
following questions must be answered. Can all the possible steering system failures be 
detected? In other words, can we distinguish between a failure and normal operation? 
It follows that if all failures can not be detected, can we prevent those that are 
invisible to the AUV's available signals and sensors? Finally, is it possible to 
distinguish between the detectable failures so that proper action can be taken in 
response? The answers to these questions will become apparent in the remainder of 
this work. 

In analyzing Table 3.2, it can be assumed that any failed response that has a 
steady state or transient difference with the normal response can be detected. A 
difference that increases without bound is considered very easy to detect. Excluding 
two of the failure modes (high r sensor noise and bias on V sensor) it is possible to 
detect and distinguish between all steering system failures studied. It will be shown 


later that high r sensor noise does not have a large enough effect on the vehicle to 
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even be called a failure. Also, it will be shown that preventing ‘Y sensor failures is 
essential for proper steering system operation. 

It may be assumed that when the difference between the failed and normal 
responses 1s steady or increasing, there is a failure. The system then has only to 
determine the exact nature of the failure and what its response will be. But what if 
the failure only shows up as a transient? It is not good practice to assume a failure 
has occurred after detecting it once (false alarms do happen). Some failures require a 
maneuver to verify them, because their normal and failed responses coalesce after the 
transient is over. Once such a failure has been detected, it is proposed that the 
maneuver of Figure 3.1 be performed for verification. It is also suggested that this 
maneuver be executed periodically, whenever the vehicle is not performing any course 
changes, so as to be able to detect one of these failures early rather than when the 
vehicle is in a critical situation. 

One more thing that can be seen from Table 3.2 is how the observer errors 
respond to the various failure modes. It should be noted here that e,, and-e,y are 
always zero unless a failure has occurred. Figures 3.2 and 3.3 show e,, vs time and 
€,y VS time respectively for the maneuver of Figure 3.1. The only variation in the two 
signals can be attributed to sensor noise. If ‘¥ sensor failures are prevented and r 
sensor noise is not considered a failure, then e,, and e,y alone can be used to 
determine if a failure has occurred. Any non-zero value of e,, or e,y can indicate there 
is a problem. Of course, if this non-zero value was just a transient then the maneuver 


of Figure 3.1 must be carried out to verify the failure actually exists. Once it has been 
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determined that there is a problem, e,, and e,, can be used together to distinguish 
whether a rudder problem or an r sensor problem exists. If a rudder problem exists, 
only e,, will be non-zero. If an r sensor problem exists, both e,, and e,y will be non- 


ZCTO. 


E. RUDDER FAILURES 


I. Loose Rudder 

In reality a loose rudder is one that is no longer coupled to its servo 
mechanism and is at the mercy of the hydrostatic forces in the water. It is assumed 
here that a loose rudder is one that is stuck at zero. We could even call this a special 
case of a stuck rudder. The steering system will still operate with a loose rudder, but 
the vehicle dynamics will be slowed down. In other words, it will take a little longer 
for the vehicle to perform the desired course change. The severity of this failure mode 
can be measured by the magnitude of the transient of e,,. 

Ihe le, | < 0.05, then the ship will still be within one ship length (7.3 ft) of its 
desired track after the completion. of a 90 degree turn, thus no action will be taken 
(failure severity is low). A 90 degree turn was chosen because this corresponds to the 


suggested maneuver of Figure 3.1. 








PCOS < 0.075, then a 90 degree turn will result in the vehicle being 


Cor 
off its course by more than one ship length but enough rudder response remains to 


correct the problem. The problem is corrected by increasing the magnitudes of the 


os 


controller gains in order to speed up the response of the remaining rudders. This has 
the effect of speeding up the already slowed dynamics of the vehicle. With the 
controller gains changed the vehicle can perform its 90 degree turn and still stay 
within one shiplength of its desired track. 

If le. | > 0.075, then the failure can not be corrected to keep the vehicle 
within one ship length after a 90 degree turn. This would be cause to abort the ’ 
mission. 

In the loose rudder scenario studied in this work both bow rudders were stuck 
at zero. Figures 3.4 and 3.5 show e,, = 'T' and e,, ='N'. Also, the magnitude of e,, is 
approximately 0.05. Figure 3.6 shows that the path followed by the vehicle is about 
one ship length off of the normal path. To verify that the observer errors are correct, 
the vehicle can check its individual rudder position sensors. Figure 3.7 shows the 
upper bow rudder to be stuck at zero. This failure can be corrected by increasing the 


controller gains, thus speeding up the vehicle's turn. 


jap Stroke Limited Rudder 

For the purposes of this work a stroke limited rudder is sis that no longer has 
its full range of motion. This could be caused by a faulty servo mechanism or a 
foreign object physically limiting the rudder's travel. Like in the case of a loose 
rudder, the steering system will still perform its job but vehicle dynamics will again be 
slowed down. The exact same procedure, as in the loose rudder case, is used to 


determine the severity of this failure. As before, the correction (if required) will be to 
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increase the controller gains to speed up the rudder response. However, if le, | = 
0.075 then there 1s not enough rudder control remaining to correct the problem and 
allow the AUV to operate effectively. 

In the scenario studied here, both stern rudders are limited to +0.2 rads. 
Figures 3.8 and 3.9 show e,, = 'T' and e,y ='N'. Since le, | < 0.05 this failure is 
considered tolerable and a correction is not made. The vehicle is only off course by a 
few feet as seen in Figure 3.10. Had this failure been more serious and corrective 
action necessary, it could be verified that the observer errors were correct by checking 
individual rudder position sensors as in the loose rudder case. Figure 3.11 shows that 
the upper stern rudder was limited to 0.2 rads rather than saturating at 0.4 rads as it 


should have if it had its full range of motion. 


S. Stuck Rudder 

A rudder is stuck if it will not move regardless of the signals sent to the servo 
mechanism. This can be caused by some foreign object preventing the rudder's 
movement, or maybe the commanded rudder signal simply 1s not getting to the servo 
to change the rudder's position. Since the normal and failed responses of nearly all the 
signals studied in this work show a definite difference in steady state, no maneuver Is 
required to verify it. However, the actions required are a little more complicated than 
in the loose or stroke limited cases; and a maneuver will be required anyway to ensure 


the vehicle can still operate effectively. 
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The way to combat this failure is to first get the vehicle pointed in the nght 
direction again. This is done by adding a bias to ‘Y..,, that will account for the servo 
error. This bias is the only one that is added to affect a change in the vehicle's 
subsystems. Other bias signals must be added for the purpose of removing the steady 
state differences between the normal and failed responses so that the steering errors are 


compensated. For example, the controller will still receive ~ from the state estimator, 


Other signals besides 


however the failure detection software will get ~ 


eee ; 
V"Voias 
that require bias additions are ; (this resets e,.) and e,. Now, as in the loose or stroke 


limited cases, the steering system dynamics have been slowed because the remaining 
rudders are compensating for the stuck rudder. So again the maneuver of Figure 3.1 
must be executed to see if the controller gains must be raised to allow the vehicle to 
respond fast enough. In some extreme stuck rudder cases le, | > 0.075, at which 
point the mission must be aborted. 

In the stuck rudder scenario from Table 3.1, e,, ='S' and e,y ='N' (Figures 3.12 
and 3.13). Individual rudder sensors must be used to verify that the observer errors 
are not incorrect and to ensure that the wrong failure is not being evaluated. The 
signals that the AUV would analyze in the case of no rudder response are similar to 
the stuck rudder case, except for the rudder position. Figure 3.14 shows the upper 
stern rudder is stuck. The next thing to check is the servo error; if it 1s increasing 


without bound then the vehicle can not correct the stuck rudder problem using the 
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other rudders and the mission would be aborted. In this case, however, servo error 
does not increase without bound (Figure 3.15). Now the vehicle must be pointed in 
the right direction and the proper biases must be inserted. Then the maneuver of 

Figure 3.1 must be performed to determine if controller gain change is required. In 


this case Je 








< 0.05 (see Figure 3.12), so no gain changes are necessary. The 


Or 


vehicle's path for this scenario is shown in Figure 3.16. 


4. Hard Rudder 

Simply put, a hard rudder is just a special case of a stuck rudder. In this case 
the rudder is stuck at an angle of +0.4 rads (the maximum rudder angle allowed). It 
can be caused by the same things that created the stuck rudder. It can also be caused 
by a wire that has shorted itself to some source of voltage that would then saturate the 
signal going to the servo mechanism. Since this is still a stuck rudder case the 
indications are the same; and the actions required to combat the failure are identical to 
those of the stuck rudder case. 

In the scenario studied here (Table 3.1) both stern rudders are stuck hard at 0.4 
rads. Again it is shown that e,, = 'S' and e,, ='N' (Figures 3.17 and 3.18), as in the 
stuck rudder case. Rudder sensors are checked to ensure the observer errors are 
correct and that it is not a 'no rudder response’ case. The servo error is then checked 
(Figure 3.19) and it is found to be increasing without bound. This makes sense 
because the stern rudders have a larger effect on vehicle steering than the bow rudders. 


This is due to the larger moment arm of the stern rudders, since they are located 
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further from the center of gravity than the bow rudders. The mission must be aborted 


since the vehicle can only go in circles (Figure 3.20). 


Sh No Rudder Response 
In this case none of the rudders move in response to a commanded course 
change. This could happen if all four rudders were simultaneously stuck at zero or if 


O.om = 0 due to a wire being shorted to ground. In the scenario of Table 3.1 the 


vehicle first detects that e, = 'S' and e,y ='N' (Figures 3.21 and 3.22). The rudder 
sensors are then checked and it 1s found that they are all stuck at zero. Figure 3.23 
shows the upper stern rudder response and it is in fact stuck at zero. Also, the vehicle 
continues to move in the same direction despite the commanded course change (Figure 


3.24). The wiggle of Figure 3.1 can be attempted to see if maybe this 1s a temporary 


condition, but if no response is noted by the rudders the mission must be aborted. 


F. YAW RATE SENSOR FAILURES 


1. Increased Yaw Rate Sensor Noise 

Many different types of interference can increase sensor noise. The worst kind 
of interference can come from jamming, which is very possible if the AUV is used for 
military purposes such as mine countermeasures. In this work a 90 degree heading 
change was ordered while the r sensor experienced a noise increase by a factor of ten. 
From Figure 3.25 it can be seen that the vehicle's path was nearly unaffected by the 


increased noise. It is therefore assumed that a noise increase in the r sensor does not 
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constitute a failure and the detection software will not even consider it an option when 


conducting failure analysis. 


Pa Loss of Yaw Rate Sensor 

If the vehicle experiences a loss of r sensor input, the state estimator will 
simply receive sensor noise. Similarly, if the entire sensor is lost (no output) the state 
estimator will receive an input of r = 0. Both cases are lumped into one here since the 
sensor noise has little effect anyway. In the scenario found on Table 3.1, the loss of 
input to the r sensor is used to study this failure. Figure 3.26 shows that by losing the 
r sensor the vehicle can still operate effectively. Given a 90 degree turn it is off 
course by only about six feet (less than a ship length). Therefore, this is not a failure 
that even needs to be accounted for by the detection software. However, we now 
know that if a more severe failure occurs in the r sensor, the solution will be to ignore 


the sensor's output and call it zero. 


3. Saturated Yaw Rate Sensor 

A saturated r sensor could occur when there's a short in the sensor circuit. The 
severity of this failure on the vehicle's path can be seen in Figure 3.27. To determine 
this failure has occurred the vehicle circuitry would detect that e,, = 'S' and e,y ='S' 
(Figures 3.28 and 3.29). It can be verified that the observer errors are accurate by 
checking that there is a steady state e, (Figure 3.30) while 6,,,, steadies out to zero 


(Figure 3.31). The response to this failure is to ignore the r sensor output and set it to 


Sy) 


zero. This is the chosen action since it has already been shown that the vehicle can 


operate effectively without the sensor. 


4, Bias On Yaw Rate Sensor 

The effect on the vehicle's path of a bias on the r sensor 1s shown in Figure 
3.32. Again e,, ='S' and e,y ='S' (Figures 3.33 and 3.34). As in the saturated sensor 
case, verification can be obtained by showing that there is a steady state e, (Figure 


3.35) while 6,,,, steadies out to zero (Figure 3.36). The proper response would be to 
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operate without the sensor, as was done in the saturated case. 


G. HEADING ANGLE SENSOR FAILURES 


The study of ‘¥ sensor failures is simple and straight forward. The ‘Y sensor is 
the primary sensor of the steering system, so its importance can not be 
overemphasized. Since it is desired that failures not occur with this sensor, it is 
proposed that the vehicle be supplied with three of them. This does not mean three 
Separate inertial units are required; magnetic compasses are low cost and reasonably 
accurate. When one sensor fails there will still be two more to supply the correct 
heading. The two failure modes studied in this work were chosen to show the 
importance of having three sensors. With this in mind, there will be no discussion as 
to how it will be detected or what actions will be taken. With three sensors on board 


it will be assumed that failures of the ‘Y sensor will not occur. 
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With a stuck ‘Y sensor the vehicle can not measure its heading (knowing only 
one direction). As soon as a Y,,. other than the stuck position of Y is ordered the 
vehicle will simply move around in circles (Figure 3.37). This would be difficult to 
detect and correct since e, (Figure 3.38) and r (Figure 3.39) contradict each other. The 
constant e, would indicate the vehicle is traveling in a straight line, but the constant r 
indicates it is moving in a circle. 

An unknown sensor bias added to ‘Y would cause the vehicle to move in the 
wrong direction. It would alter the AUV’'s course by an amount equal to Y,.,. (Figure 


3.40). What is even worse than this 1s the fact that this failure mode 1s completely 


undetectable. Figures 3.41 through 3.44 show e,,, e,y, ¢, and 6,,,,, respectively. The 


com> 
only significant difference between the normal and failed responses occurs at five 
seconds when the bias is inserted. Once the bias is inserted, the normal and failed 
responses are identical. If the bias already existed, it would not be detected. 

Similarly, if the occurrence of the bias was caught it would not be able to verify it. It 
is possible that a problem like this could be noted on successive navigational fixes, but 


then the system would have to be able to distinguish between ‘Y,,,. and normal set and 


drift. 


H. SUMMARY 


It must be noted here that when the AUV controller detects a failure and 
responds accordingly, it does not necessarily know the exact nature of the failure. For 


example, whether the r sensor is saturated or has a bias is not a concern. The system 
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need only know that there is an r sensor problem so that its value can be ignored and 
set to zero for the estimator. Similarly, the procedure used to correct a rudder failure 
seeks only to ensure the vehicle can operate effectively. It does not care which rudder 
is actually causing the problem. This extra information can be determined when the 
mission is over and the vehicle can be tested. 

In this chapter a comprehensive FMEA was conducted on the Phoenix AUV 
steering system. Several possible failure modes were analyzed. The results of these 
analyses provide methods to detect the various failures and what to do when they 
occur. These results have been ordered into a useful algorithm to be incorporated in 
the AUV's software for failure detection and resolution. This algorithm has been 
included in this work as Appendix D. 

Remember that this chapter deals only with the steering system. The algorithm 
of Appendix D would obviously be running in conjunction with other failure detection 
algorithms. For example, there should also be algorithms for the propulsion and 
diving systems. It is a fact that when there is a stuck rudder (and the other rudders 
are turned to make up for this) the drag from the rudders will slow the vehicle down. 
Also, the act of conducting a turn will slow down the vehicle. Speed was not 
considered to be a signal monitored by the steering system. However, the propulsion 
system could be used to distinguish between a stuck rudder and no rudder response, 
rather than measuring all the individual rudder position sensors. A reduction in speed, 


as sensed by the propulsion system, could indicate the rudders have moved. Finally, 
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in the case of a rudder failure (such as a stuck rudder), the propulsion system may also 
need to take action, such as increasing propeller rpm's to maintain speed. 

The last issue needing some attention is the action taken when the failure 
detection system is not working properly. What happens if the detection system reads 
a combination of signals that it can not map to a specific failure mode? The worst 
case must always be assumed. In this case it must be assumed that the failure 
detection system 1s not working properly. Therefore, if a failure occurs it may not see 


it. There can only be one solution to this dilemma: abort mission. 
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Table 3.1 Failure Scenarios 


Loose rudder 








Y 6m Changed to -1.571 rads at 5 seconds. 


6. and 6,,, stuck at zero 





Stroke limited rudder Y «om Changed to -1.571 rads at 5 seconds. 


6,5 and 6,,, limited to + 0.2 rads 


Stuck rudder Y 6m Changed to -1.571 rads at 30 seconds. 


Ou15 Stuck at 0.2 rads at 5 seconds 


Hard rudder 6,,; and 6, go hard over to 0.4 rads at 5 seconds 


No rudder response Y om Changed to -1.571 rads at 5 seconds. 


All rudders stuck at 0.0 rads 


Increased rsensor noise | Y.,,, changed to -1.571 rads at 30 seconds. 


Sensor noise increased 10X throughout simulation 


Loss of input torsensor | Y,.,, changed to -1.571 rads at 5 seconds. 


No sensor input (reading noise only) 


Saturated r sensor Sensor saturates (r = 0.873 rad/s) at 5 seconds 













Bias on r sensor Y om Changed to -1.571 rads at 20 seconds. 


Bias of 0.2 rad/s inserted at 5 seconds 
sd 


Sensor stuck at 0.0 rads 


Stuck Y sensor changed to -0.524 rads at 5 seconds. 


com 










Bias on Y sensor Y om Changed to -1.571 rads at 30 seconds. 


Bias of 0.2 rads inserted at 5 seconds 
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Figure 3.1 Vehicle Position Plot for a Typical Maneuver 
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Figure 3.4 Loose Rudder (e,, vs time). 
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Figure 3.5 Loose Rudder (e,y vs time). 


48 


upper bow rudder angle (rads) 


-10 





= normal ; : 


- — failure 











-10 0 10 20 30 40 50 60 
X (ft) 


Figure 3.6 Loose Rudder (Position Plot). 
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Figure 3.7. Loose Rudder (6,,, vs time). 
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Figure 3.9 Stroke Limited Rudder (e,, vs time). 
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Figure 3.12 Stuck Rudder (e,, vs time). 
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Figure 3.13 Stuck Rudder (e,, vs time). 
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Figure 3.17 Hard Rudder (e,, vs time). 
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Figure 3.18 Hard Rudder (e,, vs time). 
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Figure 3.19 Hard Rudder (e, vs time). 
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Figure 3.20 Hard Rudder (Position Plot). 
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Figure 3.22 No Rudder Response (e,y vs time}. 
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Figure 3.23. No Rudder Response (6,,, vs time). 
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Figure 3.25 Increased r Sensor Noise (Position Plot). 
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Figure 3.26 Loss of Input to r Sensor (Position Plat). 
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Figure 3.28 Saturated r Sensor (e,, vs time). 
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Figure 3.29 Saturated r Sensor (€,y vs time). 
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Figure 3.30 Saturated r Sensor (e, vs time). 
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Figure 3.31 Saturated r Sensor (6,,,, VS time). 


62 


(44) X 


Ot 


Od 


O€ 


OS 


O9 


OZ 


O08 


== 


Ooms 


Oca 


Aoast haltehal have ser a vey tae: 


Figure 3.32 





| | | 
£ Ww NO 
© © = 
| 
3g 2: 
SoS. 
= 3 
Oo 
/ 
/ 
/ 
Y; 
/ 
= v 
oe. Y 
re oe 2 ee 


Bias on r Sensor (Position Plc). 


63 


a 
© 
/ 
eee 
/ 
vy 
Q 
/ 
oe fare 
/ 
ie 
/ 
ms 
Joti renee 
Jo 


heading angl- observer error (rads) 


0:25 


—— normal 


- - fajlure 


| 
! 
x 
YW 
= | 
w t 
ne ! 
o 
= 
o | 
— 
a) j 
‘ad 0.1- a | 
o 
a | 
fe) 
Oo } 
® 
© ! 
= } 
3 { 
> 
t 
} 


0 be Af loli cbeeiniy PW yer| 


re 


35 — Sa Pa 


~ 


} ! ! ood fe Pop | f 1 et 4 \ 

"" Vey Gren te ea \ Ip ty vy dat on vavy vA aay Vat om ee 

rH My eyy Tae ily nil ry NS sey wed ry! wh yak ce ue hi! ‘ 
eae teen! a : ; P ( 


O.0O5F 








0 5 10 ie 20 2s 30 5 40 


time (sec) 


Figure 3.33. Bias on r Sensor (e,, vs time). 
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Figure 3.37 Stuck Y Sensor (Positio:: Plot). 
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0.02 


Da iadk il 


i 
© 
oO 
Nh 


a 18 


0.08 | | | | me ws / 
| | | | 

| 

| 


sensor yaw rate (rad/s) 





| | i ' { 
—O:12- Ke 7 ‘iy, F, WU 


h 
| A ,! 
aa aah Bi Ny aN Yi rh NN I im bide ih t 4! . b me - ih 'r 









Talk td ey Heiitigh a tpt 
yt i ; 1 \ {| 
-0.14 3 ; ! 7 : 
0 5] 10 tS 20 35 30 35 40 45 50 


time (sec) 
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Figure 3.40 Bias on Y Sensor (Position Plot). 
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Figure 3.41 Bias on Y Sensor (e,, vs time). 
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IV. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 

It has been shown here that SIMULINK can be used to design an effective 
FMEA tool. The steering system of the Phoenix AUV was modeled and used to 
simulate possible associated failure modes. The problem of inserting failures was 
solved through the use of switches that were actuated by a running clock during the 
simulations. These switches made the simulator more user friendly, allowing the 
scenario of any simulation to be easily changed at will. 

Through intensive study it was found that observer errors could be used to 
determine if a failure has occurred. These observer errors can also be used to 
determine the type of failure that has occurred (rudder or sensor). Other signals 
available to the AUV are used to verify these findings. It was also determined that 
rudder failures are far more complex to analyze and resolve than sensor failures. Also, 
since some failures can only be detected during a heading change, it was decided that 
a maneuver must be executed to verify these failures. This maneuver would also be 
performed periodically when the vehicle is travelling in a straight line, thus allowing it 
to essentially verify every now and then that everything is operating properly. 

When a loose or stroke limited rudder occurs vehicle dynamics will be slowed. 
The magnitude of e,, can be used to measure the severity of the failure. If it is low, 
no corrective action is needed. However, certain failures will require that the 
controller gains be increased to speed up the response of the operable rudders; still 


other cases will require that the mission be aborted. 
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The occurrence of a stuck rudder (hard rudder included) requires that we check 
e. first. If it is not increasing without bound, then the vehicle may be able to correct 
the problem, otherwise it must abort the mission. To correct this problem a bias is 
added to ‘V..,, so as to get the vehicle pointed in the right direction again. Buases are 
added to various other signals to compensate for their errors. Now the vehicle 
responds as though it has a loose or stroke limited rudder, and the procedures 
governing those failures must now be followed. 

When there is no rudder response the steering system can not perform its 
function, therefore the mission must be aborted. To the failure detection system no 
rudder response looks a lot like a stuck rudder. For this reason the individual rudder 
position sensors must be checked to verify the correct failure before taking corrective 
action. 

Yaw rate sensor failures are more cut and dry than rudder failures. Increased 
sensor noise and loss of sensor do not affect the vehicle enough to even be called 
failures, therefore they do not need to be watched for. However, the fact that a loss of 
r sensor will not adversely affect the vehicle makes it easy to respond to any other r 
sensor failures. If the sensor incurs a bias or becomes saturated, the solution is simply 
to ignore it and use a value of zero for the estimator. 

Since the ¥ sensor is the primary sensor of the steering system, it was assumed 
and later proven that preventing failures was the better way to go than trying to detect 
and correct them. By providing the AUV with three auctioneered sensors, it can be 


assumed that failures associated with ‘Y will not happen. 
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Finally, to sum up all the results obtained in this work dealing with detecting 
and correcting failures, an algorithm was developed (Appendix D). This algorithm 
needs only to be converted into a useful format for insertion into the AUV tactical 


level software for testing. 


B. RECOMMENDATIONS 


The FMEA tool that has been designed here 1s capable of simulating the 
occurrence of any failure mode. The results of the simulation can then be compared to 
a normal response. This is the scope of what the tool can do. It is recommended that 
before the algorithm of Appendix D be tested on the vehicle, it should be tested 
through simulation. The simulator should be run in conjunction with the algorithm, 
however the simulator must be modified to be able to take the proper corrective 
actions as determined by the algorithm. Once the validity of the algorithm has been 
proven through simulation, it can then be loaded into the AUV's software and tested in 
a real environment. 

It is also recommended that the analyses done in this work be done to the other 
Phoenix subsystems, such as propulsion and diving systems. Also, once an algorithm 
exists for each subsystem of the AUV, they must be coupled to work together in 
keeping the vehicle operational. For example, the propulsion system is affected by 
rudder changes. The analyses done on the steering system assume that speed is kept 


constant by the propulsion system. 
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Finally, the simulator designed in this work assumes that only r and ¥ are 
measured, therefore v only has an estimated value. Since we know that v can be 
measured using the doppler sonar, the simulator could be redesigned to include a 
measured v. It may be beneficial to perform the FMEA with a measured v. On the 
other hand, the addition of another sensor adds another set of possible sensor failures, 
and it has already been proven that the steering system can operate effectively with the 


Y sensor alone. 
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APPENDIX A. CONSTANTS AND COEFFICIENTS FROM BAHRKE (1992) 
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o (slugs/ft’) 1.94 
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APPENDIX B. MATLAB PROGRAM USED TO GENERATE SYSTEM 
NOISE FOR INCORPORATION INTO THE VEHICLE 
STEERING SYSTEM MODEL (OBTAINED FROM 
PROFESSOR HEALEY) 


Ib=8- 
mesons - 0. Ose) | 
e005; 

Mea) =size iw) ; 
S—wW 


mone = 12m 
Pt ene 2 (1) 5) exp (-33 .56/h° 2/7 ia) ee 
end; 


mie] 10.3-02G5:2) > 
moO. 1 LOU. 
Mme=iwenros (ie lencgien(e)); 


mee 1=1-lengeh (ws) ; 

@mt=—rand(l, length (ws) ) ; 

phi=phi-mean (phi) ; 

y(i,:)=(sqrt(S(i)*2*dw) )*cos(ws(i)*t+phi(1)*pi*2); 
end; 


mom j=l>lengtn (ws) ; 
SEN 


=Ia(els 


ee ee |S 
weave roses, 2a; 


ia 
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APPENDIX C. 


MATLAB FUNCTION USED TO AUCTIONEER AND 
AVERAGE THREE OBSERVATION ERRORS 


Pm@eerom (lu) = sensor (uu) ; 


eps=0.01; 
= Oe 
iol ae 2) {3 ) : 


(eros (al) ) ==Seps 
u=aue Us 
= | 

end; 


if abs(u(2))>=eps 
=e 2) 
<= 

end; 


It aos{u(3))>Seps 
wa a 8 


=x LL; 
end; 
aioe — 
= COC de ee | ae ae toe 
else 
Wy oe. 
end; 


gq: 





APPENDIX D. PROPOSED ALGORITHM FOR LINKING CORRECTIVE 
ACTIONS TO DETECTED FAILURE EFFECTS 


This algorithm is based on the following set of possible corrective actions: 
- abort mission 
- maneuver execution 
- bias insertions 
- ignore sensor output 


- change controller gains 


iL ife, = 'N' and e,y = 'N’ then 
goto 7 
endif 
a if €,, = 'T' or e,y = ‘T' then 
e,,— N ande,, = N’ 


| 


execute maneuver to verify failure and measure le 
if e,. = 'N' and e,y = 'N' then 
goto 7 
endif 
endif 
3) if e,, = 'S' and e,, = 'N' and all 6, = 0 (i = 1,4) then 


abort mission 








endif 
4. if e, = 'S' and e,y = 'N' and any 6, + 6,,,, (1 = 1,4) then 
if e, = 'T’ then 
abort mission 
endif 
add bias to ‘¥.... so that the vehicle will head in the right direction 
add biases to v, F and e, in order to equate the normal and failed 
responses execute maneuver to measure | €,, 
endif 
>. if e, = 'S' and e,y = 'S' and e, = ''S' and 0,,,, — 0 then 
ignore the output of the r sensor 
endif 
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6. if e,, = 'T' and e,y = 'N' and any 6, + 6.,,, (i = 1,4) then 
if 0.05 < |e, | ¢ 0.075 then 
change controller gains to speed up rudder response 
endif 
if |e, | > 0.075 then 
abort mission 
endif 

endif 
ia end of algorithm 
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